NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/76

Internet Message Format | 1996-08-06 | 4.4 KB

Path: fido.asd.sgi.com!austern
From: [e-mail] (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Throwing an exception from within a si
Date: 19 Jan 1996 09:35:54 PST
Organization: CenterLine Software
Approved: [e-mail]
Message-ID: <4doh5o$[e-mail]>
References: <4dltnb$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: 19 Jan 1996 16:34:00 GMT
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBVAwUBMP/WkEy4NqrwXLNJAQGlEgH/ddZX1EVOQWkNyKatwwfpL5s/qycUI3jC
    SQGFg4jfPhzRGvvswNkT85useg8c0NYzcLgB8RZj1nuADw+6qU6SUg==
    =Cu3c
Originator: [e-mail]

In article [e-mail], [e-mail] (Steve Clamage) writes:
> Suppose that function entry and exit are not atomic operations, which is
> the case on all systems supporting C++ that I am aware of. The "critical
> structure" is the stack frame. If asynchronous interrupts can occur, and
> if you are going to require well-defined exception behavior from signal
> handlers, then you must lock the entirety of every function preamble and
> postamble. (You cannot know that an external signal won't occur.) That
> requirement not only slows down function calls, it adds to interrupt
> latency.

As near as I can tell, the best way to do this is to slightly enhance a
PC-range-based exception-handling specification.  I was pushing for
this for the Sparc V9 ABI when I worked at Sun, but it was tough
slogging.  I wrote an article for the JCLT a few years ago that
explained how to do exactly what you are talking about on Sparc  (two
issues in mid-1994).  The essential construct is not one that can be
expressed in C++ -- essentially, it is one where the exception handler
is within the guarded range, but the guarded range is written very
carefully (essentially, all the instructions but the last one in the
normal code sequence can be re-run as many times as necessary).  The
handler for any such guarded critical range finishes the range (e.g.,
gets you in or out of the activation record) and then does the normal
dispatch "as if" the exception arrived at a safe place.  Since stack
frame construction typically takes only a few instructions, whereas
exception dispatch takes many more, this will not have a noticeable
effect on the latency of exception delivery.  Locking is not required,
so you don't pay for that, either.  This technique is portable (as far
as I can tell, from a cursory study) to all RISC architectures, and I
suspect it would port to Intel without too much trouble.

> What we put in the language standard is binding on all implementations. We
> try to specify things that can be implemented efficiently on any likely
> system. In addition, we try to specify features so that they have no cost
> (or nearly no cost) if you don't use them. IMHO, guarantees about what you
> can do in an asynchronous signal handler don't meet those criteria for
> inclusion in the C++ standard.

I think I've just described a way to do this that is efficient on any
likely system, and that has no runtime cost if you don't use it.  You
can read about it in a journal.  It isn't, to my knowledge, patented.
There's an expansion of code and table space, but if you engineer it
right (take a look at how Sun does their PC-ranges for C++ exceptions;
they're completely position-independent, and need not even be paged
in from disk unless an exception is raised) you'll never load it into
memory.

An additional stunt is simply to have your exception-handler recognize
standard function pre and post-ambles, or standard phases of activation
record construction, and avoid the need for additional code.  For
instance, it could merely interpret the preamble to the end, then raise
the exception, and that would not cost more than 100 instructions
(figure 20x cost to interpret 5 instructions).  In the case of the
Sparc SvR4 ABI, there's one way to unwind a leaf routine, and another
way to unwind a normal routine.  There's a variety of ways to solve
this problem, depending upon your code size and latency and throughput
constraints.

Of course, some of this may seem like magic to some people, but then maybe
those people shouldn't be implementing C++.

speaking for myself,

David Chase
---
[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]